SENDING ELECTRONIC MAIL TO VARIOUS NETWORKS

[The applicability of all this to SAIL has not been verified.]

Date: Sun, 20 Aug 89 16:09:21 PDT
From: <wagner@arisia.xerox.com>
To: su-computers@score.stanford.edu
Subject: E-mail routing


[I have received 32 requests for posting this, so here it is.]

I hope this posting helps shed some light on the mysteries of e-mail paths.
If you have any further questions, please let me know. Hmm... that is...
I am leaving the country on September 4, so I guess, you'll have to ask
your questions before that date... I don't know my e-mail address in
Germany yet.

Juergen Wagner					gandalf@csli.stanford.edu
						 wagner@arisia.xerox.com

PS: I am sure there are some mistakes and inaccuracies in this article.
    Let me hear/read your comments.

---------------------------------------------------------------------------

			E-Mail Addresses and Routing
			----------------------------

		   Juergen Wagner (wagner@arisia.xerox.com)
			Xerox Palo Alto Research Center
				   April 1989


There is no universal format for electronic mail addresses (short: e-mail
addresses) because of the large number of different networks, transport
mechanisms, and operating systems involved. Attempts can be made to unify
address formats, and to have mail processing programs figure out the proper
syntax, but this may not work in special cases. 

This chapter gives an overview of the semantics of e-mail addresses, and
shows how to interprete information from various sources to construct an
e-mail address to reach some correspondent. It describes mechanisms from
the perspective of an intelligent Sendmail system as found on many
Stanford machines.


1. Mailboxes

The basic concept of electronic mail delivery is the transportation of
a piece of mail (an 'electronic letter') from some machine to some
mailbox (which could be on a different machine). We will use the term
'mailbox' to denote the target of a mail delivery process. The term
'e-mail address' will be used to denote the general information needed
to direct a piece of electronic mail to its destination (this includes a
mailbox and, if necessary, a routing part).

Two types of mailboxes can be distinguished:

  o	'Mailing lists' are mailboxes which automatically redistribute
	mail to a number of other mailboxes. Mailing lists are often used
	to name a collection of mailboxes (e.g. mailboxes of all users in
	a project or special interest group).

  o	'True mailboxes' are final destinations for mail delivery. True
	mailboxes may be realized as files (e.g. spool files for mail sent
	to users, or files to archive messages), or as pipes to programs
	which further process messages (e.g. newsgroups receiver programs,
	mail-based answering services).

Mailing lists are handled by respective entries in aliases databases,
associating a name with a list of mailboxes. True mailboxes may correspond to

  o	Users - The mailbox name is some canonical form of the user's
	account name, or some registered alias. Typically, incoming mail
	for a user is kept in a private spool file which can be processed
	by the user's mail reader program.

  o	Files - A file is used to archive incoming mail. With Sendmail,
	files are specified as absolute pathnames. For security reasons,
	files are not created if they do not exist, or if the permission
	bits are not set properly.

  o	Programs - For each incoming message, the respective program will
	be invoked with the message available on standard input. The program
	may perform arbitrary operations on the message. Sendmail does not
	make any assumptions about the actions taken by such a program. In
	particular, mail-based answering services can be implemented using
	this feature. The commonly used 'vacation' program acts as such
	a filter.

A very simple mail system could just use the account names of users on
the local machine as mailbox names. To reach mailboxes on other hosts,
one would have to specify the destination host in addition to the
name of the mailbox.

In more sophisticated mail systems, mailboxes are unique across some 'name
space' (which may be restricted to a single host), so mail processing
agents may automatically direct mail to the correct machine. In such
environments, explicit information about the destination host or name
space is only required if e-mail is sent outside the current name space. 

There is no uniform convention for constructing user names. Some sites choose
the last name, the first name, the initials, a freely chosen name, or a
name composed according to some pattern (e.g. department and running number).
Mailbox names may but should not contain any characters other than digits,
dashes, dots, and letters of a single case (lowercase or uppercase). Sendmail
maps all letters to lowercase, so it is possible to disregard case in mailbox
names.


2. Non-Local Mailboxes

It is easy to keep mailbox names unique on a single machine. In a network
of two or more machines, this is still possible (e.g. by establishing a
central authority to register and administer all mailbox names). However,
as soon as connectivity with hosts and networks in other organizations or
countries is established, a systematic way of uniquely naming mailboxes
in a decentralized manner is needed.

Typical e-mail addresses as they are in use today look like
 wagner - UNIX-style: user name = mailbox name.
 wagner.pa - Grapevine-style: user names with registries.
 HOLZV::WAGNER - DecNet-style: flat name space.
 Wagner:PARC:Xerox - XNS-style: user name, domain, organization.
 wagner@cs.stanford.edu - Internet-style: user at domain.
 cdp!pyramid!iaoobel!wagner - UUCP-style: host paths.

Each of these addresses reflects different perspectives on models of
electronic mailing. The following list tries to briefly summarize the
characteristics of some common models.

o The entire e-mail universe may be subdivided into a number of disjoint
  name spaces. Each name space has its own, independent, central registry
  which administers all mailbox names in its domain, and which guarantees
  their uniqueness. A well-defined part of each mailbox name can be used to
  uniquely specify the name space, i.e. the registry handling access to
  a particular mailbox. An example of this model is Grapevine with its
  one-level, flat registry structure. E-mail addresses in Grapevine take
  the form

	user.registry

  where 'user' is a unique user or distribution list name in the name space
  of the registry 'registry'. Example:

	wagner.pa

  is the mailbox of user 'wagner' in the 'pa' (Palo Alto area) registry.

o Similarly, name spaces can be set up on a per-machine basis. To send
  a message to a particular mailbox, the mailbox and the host it is located
  on have to be specified. This roughly corresponds to the DecNet model:

	host::user

  denotes the mailbox of user 'user' on host 'host'. The model assumes
  a flat, one-level name space, i.e. it assumes that every host knows how
  to get to any other addressable host.

o A refinement of the one-level structure with registries is offered e.g.
  by XNS, where names are unique in their name space, and where name spaces
  are uniquely characterized by two components: a domain and an organization.

	Juergen Wagner:PARC:Xerox

  is the full address of the user "Juergen Wagner" (note the space in the
  user name!) in the 'PARC' domain of the 'Xerox' organization. So-called
  'clearinghouses' provide routing information and administer the name spaces.

o The entire e-mail universe may be alternatively subdivided into a number
  of hierarchically organized name spaces. Then, an e-mail address has to
  specify a mailbox and a path along the edges of the graph of the name
  space subset relation. An example of this is the Internet Domain Name model.
  (In the context of the Internet, such paths are called 'domains'. They
  are represented by dot-separated lists of the name space names.) E-mail
  addresses take the form

	mailbox@domain

  where 'mailbox' is a mailbox name as introduced in the previous section,
  and 'domain' determines a name space in the hierarchical model, in
  which the mailbox is located. Example:

	wagner@humboldt.parc.xerox.com

  denotes the mailbox of user 'wagner' in the 'humboldt.parc.xerox.com'
  domain. This domain corresponds to the host 'humboldt' at the Palo Alto
  Research Center ('parc') of the Xerox Corporation ('xerox') which
  is a commercial organization ('com').

  'Com' is the name space of all registered commercial organizations (just
  like 'edu' stands for educational institutions, 'gov' for govermental
  institutions, ...). Within this domain, there is the subdomain 'xerox'
  of the Xerox Corporation (or within the 'edu' domain, there is the
  'stanford' subdomain). Within the 'xerox.com' domain, there are further
  subdomains (one of them being 'parc'). Finally, within PARC, there are
  subdomains which correspond to actual machines.

  Deeper nestings than levels of four components can be observed: e.g.

	FOO.EXPRES.CS.CMU.EDU

  but are not very common. Most domains contain two to four components.

o A more complex model can be obtained by structuring the e-mail universe
  as a number of independent name spaces, each of which knows about a small
  number of other name spaces. Obviously, mailboxes have to specify an id in
  the destination name space plus a unique id selecting one of the accessible
  neighbouring name spaces. To send a message to a mailbox in a not directly
  reachable name space, a path along connected name spaces has to be specified.
  Note: there might be more than one path, i.e. a strategy of finding minimal
  cost paths (with an appropriate measure of cost) would be useful. Typical
  examples of this model come from the UUCP domain (where name spaces coincide
  with individual hosts):

	host1!host2!host3!mailbox

  specifies the address of 'mailbox' which is reachable from the current
  name space by sending a message to 'host1', from there to 'host2', and
  finally to 'host3' which is supposed to know the mailbox.

  The UUnet project introduced the notion of UUCP maps and UUCPnet backbone
  sites which know about routing to all hosts registered in the UUCP maps.
  With this schema, and effectively flat domain is achieved, where the old
  path syntax is only needed to reach unregistered hosts.

There is always a tradeoff between independence of name spaces and ease
of access. The UUCP model with essentially totally independent hosts provides
the largest flexibility but it can be very hard to route e-mail through such
a network. On the other hand, Grapevine assumes the existence of a relatively
small number of registries, and requires complete connectivity information
about these registries to be available among registry sites. DecNet assumes
that all hosts directly or indirectly reachable from some point in a network
are known at that point.

Evidently, name servers or clearinghouse services are needed to propagate
connectivity information in larger networks, to avoid the need for overly
large tables listing all name spaces accessible from any point in a network.
Intelligent routing becomes a key issue.


3. Name Servers

If mail is sent between mailboxes in the same name space, the mailbox name
is sufficient to uniquely specify the destination address. However, if mail
is sent between different name spaces, the e-mail address has to contain
routing information (in the simplest case just the name of the destination
name space).

The Internet is hierarchically organized into so-called 'domains',
where leafs of the domain lattice usually correspond to real Internet hosts.
The 'Internet' is a heterogenous composition of various (more or less
autonomous) networks, such as ARPAnet, MILnet, and NSFnet. NSFnet itself
consists of several regional subnetworks: NYSERNET (New York), JVNCNET (New
Jersery), SURANET (Maryland), MERIT (Michgan), USAN (Colorado), NCSANET
(Illinois), MIDNET (Nebraska), PSCNET (Pennsylvania), SESQUINET (Texas),
SDSCNET (Southern California), BARRNET (Northern California), WESTNET
(Utah), NORTHWESTNET (Washington), and others. (ARPAnet went away in
Spring 1989.)

The Internet also includes some local internets of universities and companies.
Across the Internet, file transfer, remote login, and mail services are
offered.

Rather than keeping large tables of hosts and their IP addresses (Unique
network addresses assigned to hosts on the Internet. An IP address works
in the context of the Internet like a phone number.), a distributed
database with name servers is used. To find information about a host, the
name server of the querying machine has to start at the root of the domain
lattice and has to find a path down to the desired terminal node (host).
This is accomplished by iteratively or recursively inquiring name servers in
domains. Actually, there is one master root server (SRI-NIC.ARPA, now called
NIC.DDN.MIL) which is backed up by other root servers (A.ISI.EDU, C.NYSER.NET,
TERP.UMD.EDU, GUNTER-ADAM.ARPA, NS.NASA.GOV, and BRL-AOS.ARPA). Depending on
the physical location of the querying machine, the appropriate root server
is contacted.

To find the Internet address e.g. of "tut.cis.ohio-state.edu", the local
name server will contact the nearest root server (e.g. NIC.DDN.MIL),
and ask for name servers serving the domain "ohio-state.edu". The root
name server will respond with the following three name server records:

   TUT.CIS.OHIO-STATE.EDU (128.146.8.60)
   CHEOPS.CIS.OHIO-STATE.EDU (128.146.8.62)
   UCSD.EDU (128.54.16.1)

Since one of the servers is the machine we were looking for, we are done.
Suppose, the host was "bandersnatch.shs.ohio-state.edu" instead. In this
case, the host's IP address has not been found yet, so the search continues
with the name servers returned by the previous query.

The Ohio-State server "Tut.cis.ohio-state.edu" tells our name server that
"jabberwock.shs.ohio-state.edu" administers the "shs" subdomain, so it
can be asked next. The response from "Jabberwock" returns the IP address
for "Bandersnatch":

   Name:    bandersnatch.shs.ohio-state.edu
   Address:  128.146.89.14

A similar procedure is followed to canonicalize host or domain names.

Name servers allow us to rely on distributed knowledge about Internet domains
and their subdomains, i.e. information can be dynamically obtained on demand.
Local caching of name server responses provides a significant performance
improvement. To avoid keeping out-of-date host records, an expiration
mechanism is used where each record has only a limited lifetime which is
specified by the server the record originated from.

With the capability of name server lookups, e-mail sent to some host on the
Internet can be simply addressed to

	mailbox@domain

The local Sendmail process can perform an IP address lookup on the
destination domain "domain", contact the respective mail daemon on the remote
system, and pass on the message for local delivery on the remote host.
Routing is done on the network level, based on IP addresses. Examples of
such e-mail addresses are

	gandalf@csli.stanford.edu
	postmaster@arisia.xerox.com
	wagner.pa@xerox.com


4. What About Other Networks?

Other, non-Internet addresses follow this notation:

	frodo@inteloa.intel.com
	postmaster@iaoobelix.de
	nbaa1@ds0rus1.bitnet

This schema works fine as long as all hosts are on the Internet, and as long
as all hosts are reachable from all other hosts. However, this is not
necessarily the case. E.g. all machines at Xerox PARC are not directly
accessible from outside the Xerox internet, although mail sent through the
gateway "Arisia.Xerox.COM" will reach users at PARC. There are also
networks other than the Internet (e.g. CSnet, Bitnet, UUCPnet), which use
different transport mechanisms, naming conventions, and routing strategies,
so the name server model as described above is not sufficient because there
are no IP addresses for hosts on such networks, or because these hosts are
not reachable (for security reasons).

In order to preserve the domain-style model even for networks organized in
a different way, special domain names are assigned to hosts on Bitnet,
CSnet, UUCPnet, and other non-Internet networks. Some of the above examples
were addresses in non-Internet domains. Routing to those domains is based on
the concept of gateways or relays.

Example: frodo@inteloa.intel.com

  "Inteloa.intel.com" is only on CSnet, i.e. there is no way to reach it
  directly from hosts only on the Internet. The name server serving the domain 
  "intel.com" has to provide information about recommended Internet-CSnet
  gateways which can be used to reach Intel Oakland.

  CSNET is a "Computer Science Research Network", linking sites in the
  United States, Canada, Europe, and Asia. Only parts of CSnet (mostly the
  CSNET X25net) offer features similar to the Internet.
  CSnet sites have Internet-style domain names with Internet-CSnet relays as
  registered mail forwarders.

Example: postmaster@iaoobelix.de

  Hosts in the "UUCP" domain are a more difficult case because there is no
  central authority administering the entire domain. Any host talking UUCP is
  considered to be in the UUCP domain, disregarding reachability and
  problems of propagating connectivity information to other domains.

  UUCPnet is a large, loosely linked, world-wide network of (mostly)
  UNIX hosts. Sites are located in Europe, Asia, America, and Australia. File
  and mail transfer is accomplished by UUCP links over various transport media
  (e.g. phone lines, X25, LAN). Connectivity information is kept on backbone
  sites which keep complete maps of all registered UUCPnet hosts in the world,
  i.e unregistered UUCP hosts have to be reached via paths through registered
  UUCPnet hosts. Several backbone sites are also on the Internet (e.g.
  "uunet.uu.net" and "berkeley.edu"), i.e. they are ideal gateways.

  During the last years, the UUCPnet domain has been structured further by
  introducing national toplevel domains for registered UUCPnet hosts (e.g.
  "us" for the United States, "de" for Germany, "fr" for France). However,
  not all hosts whose names follow this convention are on UUCPnet.

  As a general rule, "berkeley.edu" can be used for UUCP hosts on the West
  Coast, and "uunet.uu.net" can be used for everything else.

Example: nbaa1@ds0rus1.bitnet

"Bitnet" is another flat pseudo-domain like UUCP which interfaces the
  Internet to a differently structured network. Bitnet is a large academic
  research network based on IBM protocols. It was originally founded by IBM,
  and today includes NetNorth in Canada, EARN in Europe, and hosts in Israel.
  Bitnet offers file transfer and mail services.

  There are several Bitnet sites which are also registered on the Internet.
  The recommended gateways are "cunyvm.cuny.edu", "mitvma.mit.edu",
  and "vm.princeton.edu". In Stanford, e-mail can be routed through
  "forsythe.stanford.edu".

Other networks:

  MFEnet is a satellite-based network connecting the Department of Energy
  (DOE) Energy Research Labs across the country to the Magnetic Fusion Energy
  (MFE) Computer Center Crays at Livermore Labs. Mail can be sent from the
  Internet to MFE sites through "nmfecc.arpa".

  SPAN (Space Physics Analysis Network) is a correlative data comparison
  network which is run by an advisory group
  managed by National Space Science Data Center (NSSDC), and uses DECNET
  protocols.  The Internet gateway is the machine known as STAR
  (star.stanford.edu) at Stanford University.

  DFN (Deutsches Forschungsnetz) links German research institutes and
  organizations. It is reachable over CSNet and UUCPnet via "gmdzi.de"
  (zix.gmd.dbp.de), or "ira.uka.de".

  AC.UK (Academic Community, United Kingdom) is the academic network of the
  U.K. with its official Internet gateway "nsfnet-relay.ac.uk". Most AC.UK
  hosts are also reachable over UUCPnet ("ukc.ac.uk" the U.K. backbone
  site).

  VNET is the IBM-internal network which is not directly accessible from the
  Internet. IBM.COM acts as a gateway for registered VNET users.

  Xerox Grapevine and XNS users can be reached through Xerox.COM. For
  XNS addresses, a special translation is necessary which maps XNS domains
  and organizations to pseudo-Grapevine registries.

  Several other national research networks can be reached over CSnet or
  UUCPnet, such as SUNET (Swedish University Network), CHUNET (Swiss
  University Network), INRIA (French University Network), JUNET (Japanese
  University Network), and ASCNET (A uucp-based academic network in Australia).


5. Mail Forwarders (MX)

In cases where mail forwarding is necessary, a domain's authorative name
servers have to provide MX records. MX records are entries in the name
server database which associate one or more mail forwarding hosts with
a particular host entry.

MX records are necessary if a particular host is not on the Internet, and
therefore needs a relay host on the Internet, or if a host does not want to
receive mail itself but would like to have it routed through a central mail
handler. Examples of MX records are:

  Host:	inteloa.intel.com
  MX:	sc.intel.com(10) hermes.intel.com(20) 

  Host: versatc.versatec.com
  MX:   ames.arc.nasa.gov(5) apple.com(10) sun.com(10) 

  Host: iaoobel.de
  MX:	relay.cs.net(10) 

  Host: oracle.com
  MX:	uunet.uu.net(200) 

The above examples show hosts to be used as mail forwarders.


6. The Pathalias Database

Sendmail is also capable of handling the UUCP-style, path-based
approach to routing. The path-based approach uses the PATHALIAS database
to lookup shortest paths to hosts or domains. This database provides a
simple routing facility based on connectivity information and connection
costs. Additional information can be added by simply appending pairs of
host or domain names and routes.

New connectivity information is broadcasted on USENET every month, so the
propagation of a particular map update will not take longer than that.
In addition to this global database, hosts may add local information such
as their Internet connectivity, local preferences for routing to
pseudo-domains (e.g. Bitnet), and unofficial connections.

The pathalias database functions as a primitive name server providing
canonicalization of host names and routing information. Routing information
is listed in the form of mail paths as described in the next section.


7. Routing - Do It Yourself!

The previous sections described the actions taken by Sendmail to
find a route to some host, either by querying name servers, or by
looking up a path in a database. Basically, these operations can also be
performed manually.

Paths are usually represented as

o  Mailbox%Domainn%...%Domain1@Domain0

  The message is sent along the path "Domain_0" to "Domain_n", unless
  one of the hosts "Domain_i" performs major rewriting on the recipient
  path. This is the normally used Internet syntax (right-to-left path). The
  notation "Mailbox@Domain" is the special case of an empty path. Note that
  the path does not have to be complete, i.e. if host "Domain_j" is able
  to figure out a path from itself to some host "Domain_j+1", it is
  sufficient to list these two domains.

o  Host1!Host2!...!Hostn!Mailbox

  (UUCP-style) This is a reversed form of the previous address style, except
  that all single-word host names in the path are interpreted to be in the UUCP
  domain. Typically, this path syntax is used in pathalias databases.

  The three variants are interchangeable, and can be transformed into each
  other. PARC Sendmail canonicalizes all addresses to the Internet style
  (%-paths).

In order to be able to perform manual routing, ways to find gateways and paths
are needed. The simplest method queries name server for IP addresses or MX
records with the "nslookup" or "host" commands. (The output of the "host"
command may look different on your system.)

Suppose we are looking for the host "cs.stanford.edu".

   humboldt%  host cs.stanford.edu
   CNAME cs.stanford.edu: Polya.Stanford.EDU
   A     cs.stanford.edu: 36.8.0.160
   MX    cs.stanford.edu: polya.Stanford.EDU(10)
   humboldt%  

This tells us that the canonical name for "cs.stanford.edu" is "Polya",
what its IP address is, and that its MX record points to itself. Here are two
other examples:

   humboldt%  host cs.utexas.edu cs.uiuc.edu
   CNAME cs.utexas.edu: cs.utexas.edu
   A     cs.utexas.edu: 128.83.139.9
   MX    cs.utexas.edu: not found

   CNAME cs.uiuc.edu: cs.uiuc.edu
   A     cs.uiuc.edu: 10.3.0.37
   MX    cs.uiuc.edu: a.cs.uiuc.edu(100)
   humboldt%

There are no MX records for "cs.utexas.edu", i.e. Sendmail has to connect
directly to this host. The records for "cs.uiuc.edu" show that it has a
mail forwarder different from itself, although it is on the Internet. The
forwarder must be used even if there is an IP address because the internet the
host is on might be hidden behind a gateway machine.

Mail to all such hosts where either an IP address, or an MX host is found, can
be addressed as

	Mailbox@Host

with an appropriate mailbox name. Sendmail will find address and MX records,
and connect to the appropriate host. Some hosts still run old versions of
Sendmail which are not capable of performing name service lookups, or which
disregard MX records. In such cases, routing has to be performed manually.

Some hosts are not on the Internet but have MX records set up:

   A     aluxp.att.com: not found
   MX    aluxp.att.com: research.att.com(0)

   A     inteloa.intel.com: not found
   MX    inteloa.intel.com: relay2.cs.net(10)

   CNAME research.att.com: research.att.com
   A     research.att.com: 10.5.0.89
   MX    research.att.com: research.att.com(0)

   CNAME relay2.cs.net: relay2.cs.net
   A     relay2.cs.net: 192.31.103.5
   MX    relay2.cs.net: relay2.cs.net(0)

The lookup for "aluxp.att.com" and "inteloa.intel.com" does not list
any IP addresses but specifies a mail forwarder. These mail forwarders are
directly reachable as we can check easily. Again, mail to such hosts can
be sent to

	Mailbox@Host

with an appropriate mailbox name. Sendmail will find A and MX records,
and connect to the appropriate host. To manually route a message, it is
necessary to specify the mail forwarder explicitely:

	Mailbox%Host@MXHost

i.e. in our examples that is

	Mailbox%aluxp.att.com@research.att.com
	Mailbox%inteloa.intel.com@relay2.cs.net

to route the message through the respective MX hosts.

Finding a path can be more tricky if the name server is unable to find any
records at all. Domains which are not registered with SRI-NIC are called
"pseudo-domains". "UUCP" and "Bitnet" are classical examples of pseudo-domains.

   A     iaoobel.uucp: not found
   MX    iaoobel.uucp: not found

   A     ds0lilog.bitnet: not found
   MX    ds0lilog.bitnet: not found

Neither A nor MX records could be found. However, since there is just a small
number of such pseudo-domains, the relays can be memorized.

For Bitnet hosts, one of the official Bitnet gateways, or the nearest
Internet-Bitnet gateway can be used:

	Mailbox%ds0lilog.bitnet@forsythe.stanford.edu
	Mailbox%ds0lilog.bitnet@cunyvm.cuny.edu

For the UUCP address, the well-known Internet-UUCPnet gateway
"uunet.uu.net" can be used, which knows all registered UUCP hosts.
Other UUCPnet backbone sites will also do. The strategy in picking
an appropriate backbone site which is on the Internet is to get as close
as possible to the final destination. Since "uunet.uu.net" handles almost
all traffic to Europe, and since "iaoobel" is located in Germany,
we choose the address

	Mailbox%iaoobel.uucp@uunet.uu.net

(If the machine were in California, "berkeley.edu" would be a better choice.)

Alternatively, national domains could be used for "iaoobel":

   humboldt%  host iaoobel.de
   A     iaoobel.de: not found
   MX    iaoobel.de: relay.cs.net(10)
   humboldt%  

which gives us an MX record for that host. The new route turns out to be
faster than the route through "uunet".

	Mailbox%iaoobel.de@relay.cs.net

Finally, if we have a look at the pathalias database, the entry for
"iaoobel" is

	apple.com!pyramid!iaoobel!%s

where "%s" will be replaced by the mailbox name. This address can be
translated into a standard Internet path:

	Mailbox%iaoobel.uucp%pyramid.uucp@apple.com

>From the link cost data given in the UUCP maps, and from our additional
information about Internet connections (the link to "apple.com" will
be very fast), this is an optimal path because it goes through only two
UUCP connections, and these are relatively fast. In fact, experiments show
that this route is the fastest we can get from "Arisia.Xerox.COM" to "iaoobel".